Summary

Almost certainly the reason K1AF's LoTW "Last upload" timestamp hasn't moved from 2025-07-28 despite every upload from this app reporting success since #185.

What's happening:

• node-forge's certificateToPem produces PEM with \r\n line endings (node_modules/node-forge/lib/pem.js:46,82,84 and util.js:1602 — encode64 wraps base64 at maxline=64 with \r\n).
• The wavelog reference .tq8 we're matching comes from PHP's openssl_x509_export, which uses \n only.
• So our tCERT block ships the certificate body with CRLF between base64 lines instead of LF. LoTW's queue processor silently rejects every QSO in the file.

Why the upload looks like it succeeded:

LoTW's upload endpoint replies <!-- .UPL. accepted --> File queued for processing as soon as the multipart POST is received — that marker means "your file is in our queue", not "we processed it". The queue worker runs later, parses the .tq8, and (in this case) drops everything because the cert body doesn't match the expected line-ending convention. Operator "Last upload" timestamp on Logbook Call Sign Activity doesn't move, and the cert holder gets a rejection email.

Fix

Collapse \r\n (and any stray \r) to \n in certPemBody after stripping the BEGIN/END markers, before emitting in tCERT.

This does NOT affect the per-QSO RSA-SHA1 signatures — those are over the canonical sign-string, not over the PEM. Only the cert body the LoTW parser ingests needs to match.

Test plan

After deploying:

• Run the SQL reset from fix(sync): emit MHz frequency to LoTW + QRZ instead of dividing by 1M #212 again (or just for new QSOs since last sync) to clear lotw_qsl_sent='Y'
• Trigger upload on /lotw → "Upload now"
• Wait 10-30 min for LoTW's queue, then check Logbook Call Sign Activity for K1AF — "Last upload" should now show today's UTC time, not 2025-07-28
• Open Your QSOs on LoTW → the new QSOs should appear
• Verify the cert-holder email got the LoTW processing confirmation instead of the rejection notice

🤖 Generated with Claude Code